プログラム受入テスト

プログラム受入テストとは、プログラム設計をしたSEが、プログラム製作を依頼したPEから納品されたプログラムに対し、プログラム設計の仕様通りに実装されていることを確認するテストを指します。

単体テスト

システム開発V字モデルでは、プログラム設計に対応するテストを単体テストとしています。ところで、プログラムの製作はプログラム設計者自らが行なうということは無く、同じ社内のプログラム製作部門、あるいはプログラム製作を担当する別会社がプログラミングするケースが、ほとんどです。それは、高品質なプログラムを製作するには高度なプログラミングスキルが必要とされており、したがってプログラム製作作業を専門的に行なうべきであると考えられているためです。
コンピュータシステムはプログラムの複合体であり、プログラム1本1本が適切に動作していることが前提となります。そこで、個々のプログラムがプログラム設計通りの動作していることを確実に保証しておく必要があり、プログラム設計書に合致した動作を確認すべき作業として単体テストが位置づけられています。

プログラム受入テスト

プログラムの単体テストでは、製作者によるプログラムの実装確認と設計者によるプログラムの仕様確認の2つのテストを実施しておくことが効果的です。

プログラム製作者であるPEは、プログラム設計書の仕様通りに実装していることを確認し、プログラム設計者であるSEに納品する責務を負っています。今回は、その確認作業をプログラム単体テストと定義しています。参照先→ プログラム単体テスト

プログラム設計者であるSEも、納品されたプログラムに対するテストを行ないますが、これをプログラム受入テストと呼びます。このテストでは、PEから納品されたプログラムがプログラム仕様通りであるかという確認をするほか、設計したプログラム仕様内容が適切であるかということを実際に動作するプログラムを以て検証する目的も含まれます。SEはプログラムの挙動を自分の脳内でイメージし、それをプログラム設計書という文書で表現しているわけですが、バーチャルなものであることから、思い違いや欠落が生じている可能性を否定できません。もちろん、プログラム設計書は自己レビューのみならず、他者からのレビューも受け承認をされた上でプログラムを製作するPEに提示していますが、設計書のレビューは機能重視で行なわれるケースが多く、操作性や視認性といった面はプログラムの実装によって初めて確認している(できるようになる)といったことがあるというのが実態です。

単体テストを製作者であるPEだけでなく設計者であるSEも実施するというのは、ダブった作業をしているわけではなく、視点の違いにより行なわれているものであり、それぞれに必要な作業で実施効果が高いものといえます。

プログラムの統一性

プログラム受入テストでは、個別のプログラムの実装状態をチェックするだけでなく、他にも確認しておくべき事項があります。それはシステム全体の統一感です。

システムの設計時には、共通仕様設計としてシステムを横断した共通的な設計方針を決定しています。しかし、設計作業を進めていくと、プログラム間で同じように振舞うべき仕様が見つかることがあり、設計の途中段階で共通仕様を追加修正する作業が発生することが多々あります。
この時、システム全体の統一感が損なわれる可能性が生じます。既述分に対する追加修正では、直面する機能で要求される仕様を確定することが優先され、他部分との同期という意識があまり働かなくなってしまいます。
当該プログラム設計書に対するレビュー作業も、後から変更された部分は変更の発生都度、レビューが行なわれるため、他部分との同期が図られているか、というチェックが見落とされがちです。

また、共通仕様というものは共通化されているがゆえに汎用的な記述となっているため、個々のプログラムでの適用では多少の解釈が必要になることがあります。解釈には「ゆらぎ」というリスクがつきものであり、実装者の個性が表れてしまう可能性があります。
製作段階で実施するプログラム単体テストでは、プログラム1本単位でのテストとなるため、システム横断的な比較チェックは行なわれず、プログラム間で差異があっても気付きにくい状況にあります。そこで、プログラム受入テストのタイミングで共通仕様の実装状況を比較検証をしておくと効果的となります。

プログラム受入テストでのチェックポイント

プログラム受入テストでは、次の3つの視点でプログラムのテストを行ないます。

プログラム仕様の実装結果確認 プログラム設計書に記述された仕様が実装されているか
プログラム設計内容の結果確認 プログラム設計で定義した設計内容が適切であるか
プログラム共通仕様の実装確認 実装プログラムがシステムとしての統一性を持つか

プログラム仕様の実装結果確認

プログラム設計書に記述されている仕様通りに実装されているか、という点については製作段階でPE自身が確認済になっているはずです。SEとしては、PEが既に実施済のテスト項目をあらためてトレースする必要はありません。SEがまず行なうべき作業は、PEがプログラムとともに納品するプログラム単体テスト結果報告書の内容確認となります。
プログラム単体テストで検出された誤りの原因分析結果を査読し、適切な対処や再発防止策が実行されているかを確認します。複数本のプログラムが納品されていると、誤りの発生傾向や原因につき、偏重が見られることがあります。そういった部分はウィークポイントであり、未検出の潜在不具合が残っている可能性がありますので、SE側で再試験を実施すべきポイントとなります。

プログラム設計内容の結果確認

プログラム設計書は文書であるため、入力条件や処理結果によりダイナミックに変化するプログラムの振舞いを全て表現できるものではありません。特に要求された機能の実現が優先的に考慮されるため、使いやすさや見やすさといった非機能要件部分の実装が見落とされる傾向にあります。
そこで、プログラム受入テストとして、実際に動作するプログラムを用いて、プログラム設計内容の評価を行ないます。機能面でも設計上の見落としや不具合が無いかのチェックをするほか、個々のプログラム部品としての設計には間違いがなくても、部品を組み合わせてみると、操作するには無理があるとか、反応速度が十分ではないとか、出力結果がわかりづらいとか、プログラムとして動作することで初めてわかる問題点を検出します。

プログラム共通仕様の実装確認

ユーザは、システムに用意されているプログラムを複数使用することがあります。その際、プログラムの操作性が統一されていないと、システムを使用した作業生産性を低下させるばかりでなく、操作ミスによるエラー発生など不適切な結果を招いてしまう可能性があります。システム設計においては、共通仕様を定義し統一感を持った実装が実現できるよう考慮してはいますが、設計途中での共通仕様の追加・改訂があるだけでなく、プログラム製作者の共通仕様に対する理解不足や独自の解釈などもあり、製作されたプログラム間において、共通仕様であるにもかかわらず、独自仕様となってしまうケースがあります。
それを回避するためには、プログラム受入テストを実施する前までに、システムの共通仕様をフィックスし、統一性のあるチェック項目を用意した上で、プログラム受入テストを開始するようにしてください。

 ブログランキング・にほんブログ村へ

シェアする

  • このエントリーをはてなブックマークに追加

フォローする